Transaction management for interworking between disparate networks

ABSTRACT

The present invention enables a data-driven, dynamic transaction manager capable of coordinating interworking between disparate networks. The transaction manager is preferably provided in a gateway connecting the disparate networks. The transaction manager may dynamically determine which tasks, messages, and interactions must be involved in the fulfillment of a transaction based on a variety of data-driven sources. The transaction manager is flexible and configurable rather than a rigid architecture requiring an application-specific configuration. With the present invention, the data driving the transaction manager may involve parameters from the incoming inquiry message, parameters in data from various sources associated with the contents of the incoming message, and parameters in the gateway&#39;s behavioral configuration data, as well as parameters received in response from activities involved directly in the transaction.

FIELD OF THE INVENTION

[0001] The present invention relates to facilitating communicationsbetween disparate networks, and in particular, to providing aconfigurable transaction manager to facilitate communications betweenthe networks.

BACKGROUND OF THE INVENTION

[0002] Inherent in many communication protocols is the concept that whena message is sent to a device, the sender is expected to provide aresponse within a reasonable period of time. The device receiving themessage will traditionally decode the message and generate a reply,associating the reply with the incoming message to enable the sender toassociate the reply with the original message.

[0003] When interfacing with networks of differing technologies, devicesin one network inherently cannot communicate or understand the behaviorof devices in the other network. Interworking between such disparatenetworks may be facilitated using a gateway between the networks. Thegateway is typically configured to facilitate communications betweennetworks, but typically does not process the information beingcommunicated. The gateway is normally configured to provide atransaction manager for each supported protocol. The transaction manageris generally dedicated to specific networking applications, and thus,normally provides a very rigid response for predetermined inputs. Giventhe accelerated evolution of the number of services and types ofmessages that a gateway must handle, rigid, application-specifictransaction managers slow development and increase the cost of networksby requiring application-specific configuration.

[0004] Thus, there is a need for a general-purpose transaction managerthat is adaptive to the needs of the respective networks and theinterworking therebetween. Further, there is a need for a transactionmanager capable of dynamically reacting to the data associated with thesignaling and not merely the type of signaling between the networks. Thetransaction manager should be responsive to a variety of parametersassociated with the data wherein the parameters may be derived from anincoming message, the gateway, either of the networks, or a combinationthereof.

SUMMARY OF THE INVENTION

[0005] The present invention enables a data-driven, dynamic transactionmanager capable of coordinating interworking between disparate networks.The transaction manager is preferably provided in a gateway connectingthe disparate networks. The transaction manager may dynamicallydetermine which tasks, messages, and interactions must be involved inthe fulfillment of a transaction based on a variety of data-drivensources. The transaction manager is flexible and configurable ratherthan a rigid architecture requiring an application-specificconfiguration. With the present invention, the data driving thetransaction manager may involve parameters from the incoming inquirymessage, parameters in data from various sources associated with thecontents of the incoming message, and parameters in the gateway'sbehavioral configuration data, as well as parameters received inresponse from activities involved directly in the transaction.

[0006] The dynamic behavior of the transaction manager allows individualinstances of inbound messages in one protocol encoded in a single formatto initiate a variety of activities in the network being interfacedwithout any direct knowledge of what is required in that network. Thepresent invention also allows the selection of activities to bedependent on data arising from an inquiry in the second network, ratherthan on logic hard coded in the gateway. Additionally, the behavior ofthe gateway implementing the transaction manager is easily customized tosupport different interworking applications by simply supplyingbehavioral configuration data to select a set of desired activities andmessages, rather than building dedicated gateways or gatewayapplications for specific interworking tasks.

[0007] Generally, the transaction manager will receive an initialmessage requiring a response via a first network and build a transactionrecord including executable activities used to determine the response.The transaction manager will facilitate execution of the activities inthe transaction record. The activities may be internally executed orsent to a network device in a second network for execution. Based on thedata associated with the execution of the activities, the transactionmanager will dynamically modify the transaction record while thetransaction is processed. The transaction record is modified by changingthe activities or parameters forming the transaction record. Once thetransaction is processed by executing the activities in the transactionrecord, the transaction manager will generate and send a response to theoriginal message via the first network.

[0008] Those skilled in the art will appreciate the scope of the presentinvention and realize additional aspects thereof after reading thefollowing detailed description of the preferred embodiments of theinvention in association with the accompanying drawing figures.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

[0009] The accompanying drawing figures incorporated in and forming apart of the specification illustrate several aspects of the invention,and together with the description serve to explain the principles of theinvention.

[0010]FIG. 1A illustrates an exemplary networking environment accordingto the present invention.

[0011]FIG. 1B illustrates exemplary call signaling in the networkenvironment of FIG. 1A according to the present invention.

[0012]FIG. 2A is a block representation of a transaction manageraccording to a preferred embodiment of the present invention.

[0013]FIG. 2B is a block representation of a gateway constructedaccording to a preferred embodiment of the present invention.

[0014]FIGS. 3A and 3B illustrate a flow chart outlining a basic processaccording to a preferred embodiment of the present invention.

[0015]FIG. 4 is an exemplary activity key table according to anexemplary embodiment of the present invention.

[0016]FIG. 5 is an activity list table according to an exemplaryembodiment of the present invention.

[0017]FIG. 6 is a table illustrating an activity definition according toan exemplary embodiment of the present invention.

[0018]FIG. 7 illustrates an exemplary progression of a transactionrecord according to an exemplary embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0019] The present invention provides for an adaptive transactionmanager for a gateway connecting disparate networks. The transactionmanager is adapted to avoid proprietary configuration forapplication-specific occurrences. The transaction manager is uniquelyconfigured to operate on a variety of parameters associated with avariety of sources, including incoming signaling messages, sourcesassociated with the contents of an incoming message, and behavioralconfiguration data in the gateway, as well as responses from activitiesinvolved directly in a transaction. The dynamic behavior of thetransaction manager allows individual instances of inbound messages inone protocol, encoded in a single format, to initiate a variety ofactivities in another network without any direct knowledge of what isactually required in that network. Upon reading the followingdescription in light of the accompanying drawing figures, those skilledin the art will understand the concepts of the invention and willrecognize applications of these concepts not particularly addressedherein. It should be understood that these concepts and applicationsfall within the scope of this disclosure and the accompanying claims.

[0020] The embodiments set forth below represent the necessaryinformation to enable those skilled in the art to practice the inventionand illustrate the best mode of practicing the invention. Although thepresent invention is applicable to many types of disparate networks, aspecific combination of networks and a particular functionality isdescribed in order to disclose the best mode of carrying out theinvention and to provide an enabling disclosure.

[0021] With reference to FIG. 1A, a network environment 10 isillustrated according to a preferred embodiment of the presentinvention. The network environment 10 is depicted as including acircuit-switched network 12 interworking with a packet-switched network14. The circuit-switched network 12 may include the public switchedtelephone network (PSTN) or a wireless communication networkfacilitating like communications. The packet-switched network 14 mayinclude any type of packet-based network, but preferably is an InternetProtocol (IP), Asynchronous Transfer Mode (ATM) network, or combinationthereof.

[0022] Circuit-switched communications typically require call processingprovided over a signaling network 16, such as a Signaling System number7 (SS7) network. In SS7, a layer of the protocol called the TransactionCapabilities Application Part (TCAP) handles queries and responses fordatabases. The SS7 standards are well known. For further information seeTelcordia Technologies, GR-246-CORE, Specification of Signaling SystemNumber 7, December, 1999, which is incorporated herein by reference. Thecapabilities of SS7 have been extended by another layer, calledIntelligent Network Application Protocol (INAP). A network that featuresthis protocol is called an Intelligent Network (IN). INAP is describedin European Telecommunication Standards Institute (ETSI) Publication,ETSI-CORE-INAP-CS2, Intelligent Network Application Protocol, CapabilitySet 2, March, 1996, which is incorporated herein by reference.

[0023] The signaling network 16 will typically provide sufficient callprocessing to establish and teardown circuits required for calls, aswell as provide numerous call features during a call. Communicationsbetween the circuit-switched network 12 and the packet-switched network14 are facilitated by a media gateway (MG) 18, which is capable ofconverting circuit-switched traffic to packet-switched traffic and viceversa to facilitate media flows spanning both networks.

[0024] Typically, the circuit-switched network 12 will include a numberof switches 20 that cooperate with any number of telephony devices 22 toprovide circuit-switched connections. As depicted, the telephony devices22 may include any type of device, including wireless telephones andtraditional wire-line telephones. Generally, the switch 20 forms asignal switching point (SSP) that cooperates with a signal transferpoint (STP) 24 and a signal control point (SCP, not shown) in an SS7implementation of the signaling network 16 to form an intelligentnetwork. When providing call processing, the switch 20 will cooperatewith the STP 24 and SCP to allocate circuits and provide a number ofcall features.

[0025] As networks evolve, call processing and the number of callfeatures made available to subscribers increase. Certain of thesefeatures, such as local number portability, caller ID, automatedcallback, call forwarding, prepaid calling services and other callingfeatures, may require a signaling network 16 to cooperate with deviceson other networks to provide the call feature, access informationrelating to the call, or establish telephony communications. Forexample, telephony communications between circuit-switched andpacket-switched devices may require call setup and reservation ofresources on the packet-switched network 14.

[0026] Typically, packet-switched devices, such as the server 26, mayprovide additional call processing for circuit-switched communicationsvia a signaling gateway (SG) 28. The signaling gateway 28 mustfacilitate the interworking of the signaling network 16 and thepacket-switched network 14 to enable devices like the switch 20 tocommunicate with the server 26. Further, the server 26 may support theoperation of packet-switched telephony devices, such as thepacket-switched telephone (e.g. IP phone) 30 and the personal computer32 in a traditional client-server configuration. Thus, call processingfor either the circuit-switched or packet-switched networks 12, 14 mayrequire the switch 20 to communicate with the server 26 through the STP24 and the signaling gateway 28.

[0027] The present invention is particularly useful for gateways, suchas the signaling gateway 28, wherein the signaling network 16 and thepacket-switched network 14 use different protocols and networkingtechnologies, and devices on both of the networks must be able toefficiently communicate with one another. With this particular examplefor call processing the present invention departs from the rigid,application-specific architecture of current signaling gateways andprovides a dynamic architecture for the signaling gateway 28 tofacilitate dynamic configuration and reaction to evolving networkdemands.

[0028] To facilitate a better understanding of the basic function of thesignaling gateway 28, an exemplary call signaling sequence is depictedin FIG. 1B. In this example, assume that the signaling network 16implements the traditional SS7 protocol and the call processing requiresinteraction with the server 26, which communicates with the signalinggateway 28 using the Session Initiation Protocol (SIP). Reliable,flexible, multimedia and voice traffic over IP networks has been enabledby SIP as described in Internet Engineering Task Force (IETF) Requestfor Comments (RFC) 2543: Session Initiation Protocol, March 1999, whichis incorporated herein by reference. SIP is an application layer controlprotocol that is used to establish, modify, and terminate multimediasessions or calls. SIP provides proxiable messages used to perform callsetup, modification, and termination functions. For example, one SIPmessage used to perform call setup functions is the INVITE message. TheINVITE message is conventionally used to invite telephony devices toparticipate in a media stream communication, such as a voicecommunication, a data communication, a video communication, or anycombination thereof. The INVITE message includes a session descriptionprotocol (SDP) portion that is used by end user devices to exchangemedia capabilities and other information.

[0029] Assuming initially that the operator of telephony device 22Mdesires to call a party believed to be at telephony device 22A.Unbeknownst to the operator of telephony device 22M, the party beingcalled uses a local number portability feature, which currentlyassociates the number formerly associated with telephony device 22A withtelephony device 22B. The local number portability feature is providedby the server 26, and the signaling network 16 is configured tocooperate with the server 26 to resolve portability issues via thesignaling gateway 28.

[0030] In operation, the switch 20 will recognize an incoming call fromtelephony device 22M and cooperate with the signaling network 16 toestablish a connection with the called party, presumed to be attelephony device 22A. The switch 20 will provide the call processing“input” that is forwarded to the signaling gateway 28. As with mostprotocols, the signaling network 16 and switch 20 expect a response tothe input, but may have little or no understanding of how that responseis provided. Thus, the signaling gateway 28 will convert the callprocessing input to a corresponding message directed to the server 26.

[0031] Assuming a SIP environment, the input to initiate a call totelephony device 22A is a SIP INVITE request inviting telephony device22A to engage the communication. The server 26 will process the INVITErequest and determine that the party normally associated with telephonydevice 22A is now located at telephony device 22B. The corresponding SIPresponse is a MOVED command, indicating that the invited party is now attelephony device 22B. Thus, the response to the INVITE request receivedfrom the signaling gateway 28 is a MOVED response. The signaling gateway28 will convert the MOVED response to a corresponding signaling networkresponse that is expected by the signaling network 16 or switch 20 basedon the original input. Based on the response, the switch 20 willrecognize that the call should be connected to telephony device 22B, anda connection is made between telephony devices 22M and 22B.

[0032] As is clear from the example above, the signaling gateway 28receives an input or message from the signaling network 16, whichexpects a response to the input. The signaling gateway 28 is required toconvert the input into a corresponding message to send over thepacket-switched network 14 using the appropriate protocol (SIP). Basedon the signaling gateway's request, a response is received and convertedto a proper response for the input. For the purposes of description, theact of responding to an input or making a request is referred to as a“transaction” carried out by the signaling gateway 28. Although themedia flow setup shown in FIG. 1B is solely within the circuit-switchednetwork 12, those skilled in the art will recognize that the connectionmay bridge the circuit-switched and packet-switched networks 12, 14through the media gateway 18, or may remain solely within thepacket-switched network 14.

[0033]FIG. 2A depicts a logical representation of a transaction manager34 capable of running in a gateway, such as the signaling gateway 28, tofacilitate communications between first and second networks 36, 38. Thetransaction manager 34 will include a main logic unit 40 providing basicoperation of the transaction manager 34 and sufficient logic tocommunicate with the first and second networks 36, 38. With respect tothe first network 36, the main logic unit 40 is associated with decodelogic 42 and encode logic 44, which are configured to decode messagesfrom and encode messages to the first network 36, respectively, using afirst protocol. Similarly, encode logic 46 and decode logic 48 areprovided to encode messages to and decode messages from the secondnetwork 38, respectively, using a second protocol. In essence, the mainlogic 40, in association with the encode and decode logic 44, 46, 42,48, is configured to translate messages traveling between the networks36, 38 as well as to properly encode or decode messages travelingbetween the transaction manager 34 and one of the first and secondnetworks 36, 38.

[0034] The transaction manager 34 also includes loop detect logic 50 andtimer logic 52. The loop detect logic 50 is designed to detect perpetuallogic loops, while the timer logic 52 is used to prevent undesirabledelays in responding to a message from either of the networks 36, 38.Such delays are usually caused by a failed transaction. Both of thesefeatures will be discussed in greater detail below.

[0035] In essence, the transaction manager 34 is adapted to perform oneor more activities based on an event. Each event may trigger additionalactivities, and certain activities may initiate additional events. Thetransaction manager 34 is preferably configured to carry out activitiesinternally or to generate the proper message request to send to a deviceover one of the first and second networks 36, 38 capable of carrying outthe activity. The activities capable of being handled by the transactionmanager 34 are generally referred to as internal activities 54. Thoseactivities initiated by the transaction manager 34, but provided byother network devices, are referred to as external activities.

[0036] Importantly, any given transaction, which is typically anincoming request requiring a response, may require any number ofactivities. In a SIP environment, an external activity may be any one ofthe numerous SIP requests, such as an INVITE request. The internalactivities 54 may include any type of processing on the data or protocolconversion capable of being provided by the transaction manager 34.

[0037] In general, for any transaction, the main logic unit 40 createsand maintains transaction records 56 for the entirety of thetransaction. As illustrated, the transaction records 56 may include an“original parameter,” a “latest parameter” and an “activity list.” Theactivity list for a transaction record is basically a sequence ofactivities, or functions, necessary for the given transaction. Theactivity list may include one or more activities, and the activities maybe internal activities 54 or external activities. Further, carrying outcertain activities may require additional activities, which are added tothe activity list in the transaction record 56. As will be discussed ingreater detail below, the dynamic functionality of the transactionmanager 34 is facilitated by the ability to modify the activities in theactivity list while fulfilling a transaction.

[0038] Preferably, the main logic 40 cooperates with behavior tables 58to determine an initial activity list corresponding to a message toinitiate a transaction coming from one of the first or second networks36, 38. The behavior tables 58 will typically include initial activitiesto initiate defined transactions. Preferably, the behavior tables 58 arereadily modifiable during operation to add, delete, or change activitiesfor a transaction or add or delete acceptable transactions.

[0039] A basic gateway architecture is shown in FIG. 2B. The gatewaywill preferably include a control system 60 and requisite memory 62 tofacilitate the transaction manager 34. Further, the control system 60 isprovided with one or more network interfaces 64 to facilitate physicalinterfaces with the first and second networks 36 and 38.

[0040] The basic flow of the transaction manager 34 is outlined in theflow chart provided in FIGS. 3A and 3B. The process typically beginswhen an encoded message is received from the first network 36 (block100). The specific set of valid input messages and associated decodelogic 42 can potentially be specified in the behavior table 58. Themessage is decoded by the decode logic 42 according to the firstprotocol (block 102). The main logic 40 will process the message andcreate a transaction record 56 including an activity list derived fromthe behavior table 58 (block 104). Assuming that the message relates tocall processing, the original parameters may include the origination anddestination telephone numbers. Preferably, the original parameters donot change throughout the transaction. Any parameter changes and updatesare recorded in the latest parameter field. For the present example,assume the number for telephony device 22A has been ported to telephonydevice 22B from a call originating from telephony device 22M.

[0041] Typically, the incoming message will include a signaling code forthe transaction. The code may correspond to an activity key. As shown inFIG. 4, the transaction manager 34 may keep an activity key table, whichcorrelates an activity key corresponding to the signaling code with anactivity list identification (ID). The transaction manager 34 may alsoprovide an activity list table associating the activity list ID withspecific activities, designated with an activity ID, in a sequence inwhich to initiate the specific activities. The example in FIG. 5 depictsthree activity list IDs: AL 00; AL 12; and AL 15. Activity list ID AL 00corresponds to activities A1 and A3. Activity list ID AL 12 correspondsto activities A2, A3 and A4. Finally, activity list ID AL 15 isassociated with activity A6. The activity key table and activity listtable may be kept in the behavior tables 58 or elsewhere in thetransaction manager 34. If the incoming message did not include asignaling code from which an activity key could be derived, thetransaction manager 34 may be programmed to use a default activity listID, such as AL 00, to create an activity list having activities A1 andA3. For example, if the message corresponded to the activity key AK 01in FIG. 4, the corresponding activity list ID is AL 12, whichcorresponds to the activities A2, A3, and A4 as shown in FIG. 5.

[0042] Returning now to the flow chart of FIGS. 3A and 3B, thetransaction manager 34 will start a timer using the timer logic 52(block 106) and execute the first activity in the activity list of thecorresponding transaction record 56 (block 108). Assuming the activitylist includes activities A2, A3 and A4, activity A2 is executed. Todetermine how to execute the activity, the transaction manager 34 mayconsult an activity definition table, such as that shown in FIG. 6, foractivity A2.

[0043] The activity definition table may include several fields. Thefields may include, but are not limited to: ACTIVITY TYPE, INVOCATIONMESSAGE, RESPONSE MESSAGE, SUCCESS RESPONSE, FAILURE RESPONSE, FALL BACKRESPONSE, and SERVERs capable of fulfilling the activity. For theexample shown in FIG. 6, activity ID A2 is an external activity, asdefined by the ACTIVITY TYPE, which is configured to trigger a SIPINVITE as the INVOCATION MESSAGE. As such, the transaction manager 34will invoke the encode logic 46 to initiate a SIP INVITE to one ofSERVERs 1-4. By definition, in response to the INVOCATION MESSAGE,activity A2 expects a SIP MOVED as a RESPONSE MESSAGE. Further, uponreceipt of the RESPONSE MESSAGE from the second network 38, thetransaction manager 34 is configured to provide a CONNECT (TCAP)response over the first network 36 in response to the messageoriginating from the first network 36.

[0044] The A2 activity also provides for a FAILURE RESPONSE in case aresponse to the INVOCATION MESSAGE is not provided. The FAILURE RESPONSEcould be a line release (RELEASE) instruction. Additionally, a FALL BACKRESPONSE may include a CONNECT instruction to connect with theoriginally requested terminal. Those skilled in the art will recognizevarious options for configuring activities.

[0045] If at any time during transaction processing the timer expires(block 107 in FIG. 3B), the transaction manager ceases normaltransaction processing, generates the fall back response (block 135) andproperly terminates the transaction by encoding the fall back responseto the original message (block 136) and sending the response to theoriginal message (block 138). Everything related to any activities ofthe transaction, including any responses later received by thetransaction manager after the timer expires, is ignored.

[0046] Returning FIG. 3A, the transaction manager 34 will preferablydetermine whether the activity is an internal or external activity(block 110). For an external activity, a message associated with theactivity is encoded for delivery over the second network 38 using thesecond protocol (block 112). The encoded message is sent to the defineddevice in the second network to fulfill the activity (block 114). Thetransaction manager 34 will await a response to the message (block 116)and decode the response using the second protocol (block 118). If theactivity is an internal activity (block 110), the transaction manager 34will provide the internal activity (block 120).

[0047] After carrying out the internal or external activity, thetransaction manager 34 will modify the transaction record 56 asnecessary (block 122). As noted, the modification may include addingadditional activities, changing existing activities, or removingactivities from the activity list.

[0048] An example progression of an exemplary transaction record isillustrated in the table of FIG. 7. The table represents four loopsthrough the process flow of FIGS. 3A and 3B. Initially, the transactionmanager 34 may derive the initial activity list (A2, A3, and A4) fromthe behavior tables 58 based on the transaction requested. As such, thetransaction manager 34 will initiate implementation of activity A2.Assume activity A2 provides for modifying the original parameter andrequires the addition of another activity (A16) to the activity list. Assuch, the “LATEST PARAMETER” field is modified to represent the changein parameters while the “ORIGINAL PARAMETER” field preferably remainsthe same with the original parameters. The transaction manager 34 willprogress through the activity list one activity at a time until all ofthe activities are completed. In the example, the progression ofactivities will include A3, A4, and A16 after completing A2.

[0049] The transaction manager 34 will next determine if a loop has beendetected (block 124). If a loop is detected, the activity processingstops, a fall back response is generated (block 135), and thetransaction manager 34 proceeds to encode and deliver the response(block 136).

[0050] The transaction manager 34 will next determine whether or not theactivity has failed (block 126). If the activity has failed, theactivity processing stops, a failure response is generated (block 128),and the transaction manager 34 proceeds to encode and deliver theresponse (block 136).

[0051] If the timer has not expired, a loop has not been detected, andthe activity has not failed, the transaction manager 34 will evaluatethe activity list to determine if all of the activities have beenprocessed (block 130). If activities remain in the activity list, thetransaction manager 34 will execute the next activity in the activitylist of the transaction record 56 and continue with activity processing.

[0052] If the last activity has been executed (block 130) thetransaction manager 34 will generate a response to the original messageinitiating the transaction based on the results of the final activityand the data in the transaction record (block 134). The response isencoded using the first protocol (block 136), and sent over the firstnetwork as a response to the original message (138).

[0053] Those skilled in the art will appreciate the flexibility impartedto a gateway implementing the transaction manager of the presentinvention. The present invention enables a data-driven, dynamictransaction manager capable of coordinating interworking betweendisparate networks. The transaction manager may dynamically determinewhich tasks, messages, and interactions must be involved in thefulfillment of a transaction based on a variety of data-driven sources.A flexible, general-purpose transaction manager is provided, rather thana rigid architecture requiring application-specific configuration. Withthe present invention, the data driving the transaction manager mayinvolve parameters from the incoming inquiry message, parameters in datafrom various sources associated with the contents of the incomingmessage, and parameters in the gateway's behavioral configuration data,as well as parameters received in response from activities involveddirectly in the transaction.

[0054] The dynamic behavior of the transaction manager allows individualinstances of inbound messages in one protocol encoded in a single formatto initiate a variety of activities in the network being interfacedwithout any direct knowledge of what is required in that network. Thepresent invention also allows the selection of activities to bedependent on data arising from an inquiry in the second network, ratherthan on logic hard coded in the gateway. The transaction manager iscapable of transparently involving multiple application servers in aload sharing fashion for any type of transaction. The network issuingthe inquiry need not know the existence or details of these servers, orwhich ones are involved in a given transaction.

[0055] Additionally, the behavior of the gateway implementing thetransaction manager is easily customized to support differentinterworking applications by simply supplying behavioral configurationdata to select a set of desired activities and messages, rather thanbuilding dedicated gateways or gateway applications for specificinterworking tasks. In essence, software functions are dynamicallyselected for reuse as the transaction manager executes transactions.Network operators have the ability to change behavior in live networksby simply updating behavioral data, activity lists, or activities,without requiring a reload or restart of the system.

[0056] Many aspects of the invention may be implemented by program code.The program code together with the hardware described above may providemeans to provide the transaction manager and functionality thereof. Theprogram code may be stored on any type of computer readable medium orany type of computer or control system, such as those commonly found ingateways. For further information relating to messaging betweendisparate networks, attention is directed to U.S. application Ser. No.09/638,580, filed Aug. 15, 2000, entitled “Method and Apparatus forMessaging Between Disparate Networks,” which claims the benefit ofprovisional application serial No, 60/186,389, filed Feb. 18, 2000. Thedisclosures of these applications are incorporated herein by reference.

[0057] Those skilled in the art will recognize numerous modificationsand additional benefits provided by the present invention. Notably, asingle transaction may require more than one set of query/responsemessages. For example, the first network may send an inquiry that causesa message to be sent to the second network. Receipt of the message atthe second network causes an inquiry for more information from the firstnetwork. The first network may respond with the requested additionalinformation. As a result, the second network can formulate a response tothe original inquiry and send it to the first network. Multipleintermediate query-response messages may be needed before the originalinquiry can be answered. These additional benefits could also include,but are not limited to use of dynamic transaction manager conceptsconcurrently between numerous networks, some possibly involving similarprotocols. All such modifications are considered within the scope of theabove disclosure and the claims that follow.

[0058] Further, the dynamic transaction manager technology may be usedin situations where activities are desired on messages passing trough agateway that may be connecting networks of the same or differentarchitectures such as screening of message content for security. In thiscase, transactions may be dynamically managed even though the networksmay not be disparate but just under the control of disparate operators.

What is claimed is:
 1. A gateway for dynamically managing transactionscomprising: a) a first interface for a first network supporting a firstprotocol; b) a second interface for a second network supporting a secondprotocol; and c) a control system associated with the first and secondinterfaces and adapted to: i) receive a first request requiring a firstresponse via the first network; ii) build a transaction record includingone or more activities necessary to provide the first response for thefirst request; iii) facilitate execution of the one or more activitiesin the transaction record until no activity requires execution; iv)modify the transaction record in response to executing any of the one ormore activities; and v) generate the first response based on executionof the one or more activities.
 2. The gateway of claim 1 wherein thecontrol system is further adapted to build the transaction record tohave an activity list including the one or more activities.
 3. Thegateway of claim 2 wherein the control system is further adapted tomodify the transaction record by modifying at least one of the one ormore activities in the activity list in response to executing any of theone or more activities.
 4. The gateway of claim 3 wherein the controlsystem is further adapted to modify the transaction record by at leastone of the group consisting of: a) adding at least one activity to theactivity list in response to executing any of the one or moreactivities; b) removing at least one activity from the activity list inresponse to executing any of the one or more activities; and c) changingat least one activity within the activity list in response to executingany of the one or more activities.
 5. The gateway of claim 2 wherein thecontrol system is further adapted to update the one or more activitiesin the activity list in response to executing any of the one or moreactivities to provide an updated activity list and facilitate executionof the one or more activities in the order listed in the updatedactivity list.
 6. The gateway of claim 2 wherein the control system isfurther adapted to initially determine the one or more activities frombehavioral data corresponding to the first request.
 7. The gateway ofclaim 6 wherein the control system is further adapted to modify thebehavioral data corresponding to the first request by an operator duringoperation.
 8. The gateway of claim 1 wherein the control system isfurther adapted to build the transaction record to have a parameterfield and modify the transaction record by modifying at least oneparameter in the parameter field in response to executing any of the oneor more activities.
 9. The gateway of claim 1 wherein at least one ofthe one or more activities is an external activity requiring executionby a device on the second network and the control system is furtheradapted to facilitate execution of the external activity by: a)generating a second request directed to the device; b) sending thesecond request to the device over the second network; and c) receiving asecond response to the second request from the device over the secondnetwork, the response representing the results of execution of theexternal activity.
 10. The gateway of claim 9 wherein at least one ofthe one or more activities is an internal activity and the controlsystem is further adapted to execute the internal activity.
 11. Thegateway of claim 9 wherein the second request and the second responseuse a second protocol.
 12. The gateway of claim 1 wherein the controlsystem is further adapted to generate the first response when one of theone or more activities fails to execute.
 13. The gateway of claim 1wherein the control system is further adapted to generate the firstresponse when one of the one or more activities fails to execute withina select period of time.
 14. The gateway of claim 1 wherein the controlsystem is further adapted to generate the first response when thecontrol system falls into executing a perpetual, logical loop.
 15. Acomputer readable medium including software for dynamically managingtransactions, the software comprising computer instructions to: a)receive a first request requiring a first response via a first network;b) build a transaction record including one or more activities necessaryto provide the first response for the first request; c) facilitateexecution of the one or more activities in the transaction record untilno activity requires execution; d) modify the transaction record inresponse to executing any of the one or more activities; and e) generatethe first response based on execution of the one or more activities. 16.The computer readable medium of claim 15 comprising further instructionsto build the transaction record to have an activity list including theone or more activities.
 17. The computer readable medium of claim 16comprising further instructions to modify the transaction record bymodifying at least one of the one or more activities in the activitylist in response to executing any of the one or more activities.
 18. Thecomputer readable medium of claim 17 comprising further instructions tomodify the transaction record by at least one of the group consisting:a) add at least one activity to the activity list in response toexecuting any of the one or more activities; b) remove at least oneactivity from the activity list in response to executing any of the oneor more activities; and c) change at least one activity within theactivity list in response to executing any of the one or moreactivities.
 19. The computer readable medium of claim 15 comprisingfurther instructions to update the one or more activities in theactivity list in response to executing any of the one or more activitiesto provide an updated activity list and facilitate execution of the oneor more activities in the order listed in the updated activity list. 20.The computer readable medium of claim 15 comprising further instructionsto initially determine the one or more activities from behavioral datacorresponding to the first request.
 21. The computer readable medium ofclaim 20 comprising further instructions to modify the behavioral datacorresponding to the first request by an operator during operation. 22.The computer readable medium of claim 15 comprising further instructionsto build the transaction record to have a parameter field and modify thetransaction record by modifying at least one parameter in the parameterfield in response to executing any of the one or more activities. 23.The computer readable medium of claim 15 wherein at least one of the oneor more activities is an external activity requiring execution by adevice on the second network and the instructions to facilitateexecution of the external activity comprise: a) generate a secondrequest directed to the device; b) send the second request to the deviceover the second network; and c) receive a second response to the secondrequest from the device over the second network, the responserepresenting the results of execution of the external activity.
 24. Thecomputer readable medium of claim 23 wherein at least one of the one ormore activities is an internal activity and comprising furtherinstructions to execute the internal activity.
 25. The computer readablemedium of claim 23 wherein the second request and the second responseuse a second protocol.
 26. The computer readable medium of claim 15comprising further instructions to generate the first response when oneof the one or more activities fails to execute.
 27. The computerreadable medium of claim 15 comprising further instructions to generatethe first response when one of the one or more activities fails toexecute within a select period of time.
 28. The computer readable mediumof claim 15 comprising further instructions to generate the firstresponse when the control system falls into executing a perpetual,logical loop.
 29. A method for dynamically managing transactionscomprising: a) receiving a first request requiring a first response viaa first network; b) building a transaction record including one or moreactivities necessary to provide the first response for the firstrequest; c) facilitating execution of the one or more activities in thetransaction record until no activity requires execution; d) modifyingthe transaction record in response to executing any of the one or moreactivities; and e) generating the first response based on execution ofthe one or more activities.
 30. The method of claim 29 furthercomprising building the transaction record to have an activity listincluding the one or more activities.
 31. The method of claim 30 whereinthe modifying step further comprises modifying at least one of the oneor more activities in the activity list in response to executing any ofthe one or more activities.
 32. The method of claim 31 wherein themodifying step further comprises modifying the transaction record by atleast one of the group consisting of: a) adding at least one activity tothe activity list in response to executing any of the one or moreactivities; b) removing at least one activity from the activity list inresponse to executing any of the one or more activities; and c) changingat least one activity within the activity list in response to executingany of the one or more activities.
 33. The method of claim 30 furthercomprising updating the one or more activities in the activity list inresponse to executing any of the one or more activities to provide anupdated activity list and facilitating execution of the one or moreactivities in the order listed in the updated activity list.
 34. Themethod of claim 30 further comprising initially determining the one ormore activities from behavioral data corresponding to the first request.35. The method of claim 34 further comprising modifying the behavioraldata corresponding the first request by an operator during operation.36. The method of claim 29 further comprising building the transactionrecord to have a parameter field and modifying the transaction record bymodifying at least one parameter in the parameter field in response toexecuting any of the one or more activities.
 37. The method of claim 29wherein at least one of the one or more activities is an externalactivity requiring execution by a device on the second network andfurther comprising facilitating execution of the external activity by:a) generating a second request directed to the device; b) sending thesecond request to the device over the second network; and c) receiving asecond response to the second request from the device over the secondnetwork, the response representing the results of execution of theexternal activity.
 38. The method of claim 37 wherein at least one ofthe one or more activities is an internal activity and furthercomprising executing the internal activity.
 39. The method of claim 37wherein the second request and the second response use a secondprotocol.
 40. The method of claim 29 further comprising generating thefirst response when one of the one or more activities fails to execute.41. The method of claim 29 further comprising generating the firstresponse when one of the one or more activities fails to execute withina select period of time.
 42. The method of claim 29 further comprisinggenerating the first response when the control system falls intoexecuting a perpetual, logical loop.
 43. A gateway implementing atransaction manager comprising an interface to a first networksupporting a first protocol; an interface to a second network supportinga second protocol; and a control system adapted to process a transactioninitiated by a message received from the first network by: a) selectingan initial process for the transaction including a sequence of functionsto implement; b) for any internally executable functions of the sequenceof functions, executing the function internally, and for any externallyexecutable function of the sequence of functions: i) generating arequest directed to in the second network; ii) sending the request tothe device over the second network; and iii) receiving a second responseto the second request from the device over the second network,  whereinexecution of each function provides data relating to the transaction; c)modifying the initial process for the transaction based on the datarelating to the transaction; and d) providing a response to the messageover the first network after processing the transaction.